home *** CD-ROM | disk | FTP | other *** search
/ Aminet 1 (Walnut Creek) / Aminet - June 1993 [Walnut Creek].iso / aminet / comm / fido / xprfts072.lzh / README.FIRST < prev    next >
Text File  |  1992-11-24  |  9KB  |  216 lines
  1.  
  2.   This is the sources and binary for xprfts.library for use with
  3. the new beta's of Welmat.  When Welmat itself is close to an official
  4. release, I will be separately releasing all the XPR's that are written 
  5. as part of the project as well.  At this moment there is xprzedzap 
  6. (For ZedZip/ZedZap fidonet sessions), xprfts.library (For FTS-1, DietIFNA
  7. and soon SeaLink  transfers) and xprclock.library (For calling an atom 
  8. clock time base to set your Amiga's clock).  Work on a few different
  9. bi-directional transfer ideas has started, but no finished library yet
  10. exists.
  11.  
  12.   This library is based on much of the work and experience from the origional
  13. versions of Welmat, and has been fairly well tested.
  14.  
  15.   I have also started to add some of the possible extensions
  16. that might be added to the XPR interface (Those interested should check
  17. out the function updstatus() in support.c).  If you wish to get involved in
  18. this expansion, please contact eithor myself or Willy Langeveld for more
  19. information.
  20.  
  21.  
  22.   I will be attempting to keep the latest versions of the various XPR
  23. libraries up for fidonet file request on  1:163/109 at 2400bps, and 
  24. on 1:163/139 at 14400bps.  If you wish to help work on these libraries, please
  25. let me know ahead of time so that I can make the latest available for
  26. request.
  27.  
  28.  
  29. Thanks to Skip Watson (ciaran@aldhfn.akron.oh.us) who has offered to
  30. host a mailing list to further the development of the XPR specification,
  31. we have now started discussions on the future directions that XPR can
  32. take.  I strongly encourage any authors interested in writing
  33. hosts or protocols, whether freely available, shareware or commercial
  34. to please join us.
  35.  
  36.  
  37. For joining the list:    
  38.  
  39. xpr-request@aldhfn.akron.oh.us    with "subscribe user@site" as the body
  40.  
  41. For posts to the list:
  42.  
  43. xpr@aldhfn.akron.oh.us
  44.  
  45.  
  46. From: jbickers@templar.actrix.gen.nz (John Bickers)
  47. Date: Mon, 23 Nov 92 08:17:38 PST
  48. To: xpr@aldhfn.akron.oh.us
  49. Subject: A FAQ.
  50.  
  51.     Here's the text of the FAQ as it stands now. If you have something
  52.     to say about it, please do so. It would also be nice to see more
  53.     people on the list say whether they support, disagree with, or are
  54.     indifferent to, the various issues.
  55.  
  56.     ------------------------------ 8< ------------------------------
  57.  
  58.  
  59.     XPR Science Monitor                                       22.11.92
  60.  
  61.  
  62.     Note that "host" refers to the application using an XPR library,
  63.     2.0 is the current version of the XPR specification, and 3.0 is
  64.     the future version the XPR mailing list was created to discuss.
  65.  
  66.  
  67. **> UNSRESOLVED ISSUES
  68.  
  69.     1.  How to pass host data (eg, a4 or an XPR_IO pointer) to a
  70.         callback routine.
  71.  
  72.     There are basically two ideas, referred to below as A and B. A is
  73.     to have each top level XPR library routine accept an extra 32-bit
  74.     parameter, which it passes on to each callback routine. B is to
  75.     add a field to the XPR_IO structure specifically for host data,
  76.     then have the library pass a pointer to the XPR_IO structure as an
  77.     extra parameter to each callback routine.
  78.  
  79.     2.  How to extend the specification to allow for the passing of
  80.         these extra values.
  81.  
  82.     WRT A, the top level XPR library routines can easily be expanded
  83.     to take an extra parameter. Older hosts that call the new routines
  84.     will simply pass a random value through. Because their older
  85.     callbacks won't make use of this value anyway, it doesn't matter.
  86.  
  87.     WRT B, the XPR_IO structure can be extended by placing a magic
  88.     cookie value in a new field so a 3.0 library can tell that it has
  89.     been passed a 3.0 XPR_IO structure. Then the host field can be
  90.     added somewhere after the cookie. An older library will simply
  91.     ignore the extra fields, and an older host will not create the
  92.     cookie.
  93.  
  94.     3.  How should the callback extension work, to cater for new
  95.         callbacks that know about the extra parameter?
  96.  
  97.     The proposed solution is to use the callback extensions mechanism
  98.     in the 2.0 spec. to add a new callback called xpr_updateio(),
  99.     which must be called by a 3.0 XPR library during XPRSetup(). The
  100.     existence of this field tells the library that the host is 3.0
  101.     aware. If XPRSetup() completes and this callback routine was
  102.     called, then the host knows the library is 3.0 aware.
  103.  
  104.     The proposed function for this routine is to change the callback
  105.     slots in the XPR_IO routine to point to routines that expect the
  106.     extra parameter passed by the 3.0 spec. The host would first set
  107.     the XPR_IO up to point to 2.0 routines, then xpr_updateio() would
  108.     change the callback slots to point to 3.0 routines.
  109.  
  110.     4.  How can a transfer involving multiple files indicate a success
  111.         or failure status for each file in the batch?
  112.  
  113.     The proposed solution is that xpr_update() be used for each file
  114.     with an xpru_updatemask of XPRU_FILENAME|XPRU_STATUS, and the
  115.     success or failure status (XPRU_SUCCESS or XPRU_FAILURE) in
  116.     xpru_status.
  117.  
  118.     5.  Should the XPR structures contain cookies, so pointers to them
  119.         can be identified or verified?
  120.  
  121.     Current thinking is that if cookies are used, it should not be
  122.     necessary to check them.
  123.  
  124.     6.  Is there a problem writing a bi-directional transfer protocol
  125.         as an XPR library?
  126.  
  127.     Currently xpr_update() is designed to show the progress of one
  128.     file being transferred.
  129.  
  130.     7.  Should XPR libraries be requested not to fracture the stack
  131.         before calling a callback routine?
  132.  
  133.     The reason for this is that it means the stack trick in 1d below
  134.     can be used with less risk. Arguments against are that it should
  135.     not be necessary for a host to implement solution 1d anyway, that
  136.     it may not be reliable, and that the stack is just a push/pop
  137.     mechanism that should not be relied upon across function calls.
  138.     Arguments for are that it can be necessary under the 2.0 spec. to
  139.     do this sort of thing, and that the host should be able to expect
  140.     the stack to conform to that allocated by the OS for the host's
  141.     task.
  142.  
  143.  
  144. **> POSSIBLE SOLUTIONS TO SOME PROBLEMS
  145.  
  146.     1.  How to get a handle on host information within a callback
  147.         routine, under the 2.0 spec.
  148.  
  149.     1a  If only one handle is required per task, maintain a list of
  150.         handles paired with task addresses. The callback routine can
  151.         then use FindTask() and scan this list for a matching entry.
  152.         You need access to your data segment (a4) to be able to get at
  153.         this list.
  154.  
  155.     1b  If only one handle is required per task, use tc_Userdata, a
  156.         field in the Exec task structure. The callback routine can
  157.         then use FindTask(NULL)->tc_Userdata. This is very useful when
  158.         the data segment (a4) is not available, for example when
  159.         writing residentable programs.
  160.  
  161.     1c  If only one handle is required per data segment (a4), and this
  162.         data segment is available, simply use a global variable.
  163.  
  164.     1d  A somewhat risky solution, if a4 and tc_Userdata are not
  165.         available, is to push a magic cookie and the handle onto the
  166.         stack before calling an XPR library routine. Then the callback
  167.         routine can search back up the stack for the cookie, and thus
  168.         locate the handle. This won't work if the XPR library
  169.         fractures the stack before calling the callback routine, a
  170.         feature that some compilers support.
  171.  
  172.     2.  How can an a host tell whether individual files in a batch
  173.         file transfer were transmitted successfully, under the 2.0
  174.         spec?
  175.  
  176.     2a  Assumptions can be made in the xpr_open() callback routine
  177.         that the previous file was successful etc. Information from
  178.         other callback routines can be combined with this to add
  179.         more depth to the result. For example, if xpr_open() is
  180.         called and the last xpr_update() on the previous file did not
  181.         show xpru_filesize and xpru_bytes as being equal, then one
  182.         could assume that the previous file failed. All this is very
  183.         dubious.
  184.  
  185.  
  186. **> AGREED SOLUTIONS
  187.  
  188.     The more people add their support to the issues in "UNRESOLVED
  189.     ISSUES", the quicker they'll be resolved and be listed here.
  190.  
  191.  
  192. **> AGREED MODIFICATIONS TO DOCUMENTATION
  193.  
  194.     1.  XPR libraries must not modify tc_Userdata. That should be left
  195.         to the host level. Amongst other considerations, using this
  196.         field would break VLT.
  197.     ------------------------------ 8< ------------------------------
  198.  
  199. --
  200. *** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
  201. ***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
  202.  
  203.  
  204. ---------------
  205.  
  206.  
  207.   As well as the above, talk of asynchronous I/O, speed optimizations,
  208. methods to set and read file timestamps, etc are being
  209. discussed.  A log of the messages is being kept, so old messages
  210. can be received if the desire exists.
  211.  
  212.  
  213.                     Russell McOrmond
  214.                     aa302@freenet.carleton.ca
  215.  
  216.